home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / src / Tools / ecu-3.35 / README.Q-and-A < prev    next >
Encoding:
Text File  |  1995-07-14  |  7.1 KB  |  172 lines
  1. Last revised Fri Jun 23 02:05:20 EDT 1995
  2. -----------------------------------------------------------------------
  3.  
  4. > I have problems with lock files under SCO when I use ports
  5. > not conforming to SCO naming conventions.
  6.  
  7. Read README.SCOTTY.
  8.  
  9. -----------------------------------------------------------------------
  10. Why do I get "Device busy" on trying to open a line I know
  11. no one is using?
  12.  
  13. If you are using FAS or a driver of a similar discipline,
  14. EBUSY can be returned if (from fas.c):
  15. "If the device is already open and another open uses a different
  16. open mode or if a getty open waits for carrier and doesn't allow
  17. parallel dialout opens, return with EBUSY error."
  18.  
  19. Getty can disallow parallel dialouts if it opens a line whose
  20. "magic number" contains 11 in the the 0xC0 position.
  21. From the fas README:
  22.  
  23.    Bitmap:   m m f f x x x x
  24.       `m m' are the mode bits as follows:
  25.        ...
  26.        1 0   The device is carrier controlled. It blocks on open if
  27.              there is no carrier.
  28.        1 1   Same as mode `1 0', but a parallel non-blocking open
  29.              is possible while waiting for carrier.
  30.  
  31. Using 11 in the mm bit positions are the correct choice for ISC
  32. to mimic the ISC asy driver behavior.  On SCO, you should set
  33. these bits to 10 for the "modem" or "getty" (uppercase) name to
  34. mimic the sio driver behavior.  There are other mechanisms for
  35. handling use collisions.
  36.  
  37. If you are using some other driver, the ISC behavior may
  38. be the only option available.
  39. -----------------------------------------------------------------------
  40. One thing that I would like to see is some sort of side utility
  41. for changing colors in a shell like ecu does when I run it...it
  42. leaves the colors permanent for me.  Love the blues and yellows
  43. that I have set up for trn...makes things actually easier on the
  44. eyes to read.
  45.  
  46. Color is supported fully on SCO and partially on ISC.  Code for
  47. SVR4 has been turned off (I had reports it was "broken").  Since
  48. xterms are the only things that make sense on the Sun (who uses
  49. the console?  shelltool/cmdtool?  barf/vomit/just-say-no), color
  50. has not been attempted there.  Does anyone know about a working
  51. "colxterm." I tried long and relatively hard a couple of years
  52. ago to port it to SCO with no joy.
  53.  
  54. SCO has an ioctl(screen_file_descriptor,GIO_ATTR,&character) that
  55. returns a 6845-style attribute byte (foreground and background
  56. nibble pair).  I use that at initialization time (ecutty.c
  57. get_initial_colors()) by asserting reverse video and reading the
  58. colors, then setting normal and reading those colors.  (On SCO,
  59. "reverse" and "normal" can be set to arbitrary pairs of colors,
  60. not just flipped from each other).  These values safely
  61. squirrelled away, ECU or the user can do what they want.  When
  62. ECU exits (ecutty.c restore_initial_colors()).
  63.  
  64. This save/restore feature is turned on only for SCO (#ifdef M_SYSV).
  65. Perhaps it should be #ifdef GIO_ATTR, but SCO only included the
  66. identifier in sys/console.h recently.  I have no idea who else
  67. has it (oh yes I do ... ISC sys/kd.h has it).
  68.  
  69. If anybody wants to look into this, I'm sure there are many who
  70. would appreciate it.
  71. -----------------------------------------------------------------------
  72. > Can a finish and/or bye command(s)
  73. > be added to the kermit transfer section? We've found that we needed it
  74. > many times, and it would have been nice to be able to abort out of the
  75. > kermit server instead of hanging up.
  76. > 
  77.  
  78. With C-Kermit 5 available to ecu's $PATH, to finish a remote
  79. server active on the attached comm line, try a one line procedure :
  80.  
  81.  
  82.     system -s 'ckermit -l '+%itos(%conn)+' -b '+%itos(%baud)+' -f'
  83.                ^^^^^^^ you may have named it kermit or whatever.
  84.  
  85. You may have to play around with your .kermrc file if
  86. you have checksum/block check type problems.  This is
  87. unlikely if you have been using Kermit with ecu since
  88. you must already have a .kermrc
  89.  
  90. Or look at the following procedure.  (Does it inspire other
  91. things you could do by plugging a temporary .kermrc :-> ?! )
  92.  
  93. There may be syntax errors since I didn't test this.  What example
  94. ever has been tested:-/ ?
  95.  
  96.     #
  97.     # build tmp file with proper checksum in it.
  98.     #
  99.         $s_rc = '/tmp/'+&itos(%pid)+'.tmp'  # choose name
  100.         fdel $s_rc       # make sure it does not exist
  101.         fclose 1         # make sure file 1 is closed
  102.         fopen 1 $s_rc    # open the tmp file
  103.     #   if error opening file, complain and exit
  104.         ifi $i0 != 0 echo 'Cannot open '+$s_rc+': '+%errstr($i0); return
  105.     #            !!!!!!!!!!!
  106.         fputs 1 'set block 3'  # or whatever
  107.     #            !!!!!!!!!!!
  108.         fclose 1               # close the file
  109.  
  110.     #
  111.     # build command:
  112.     # ckermit -l <ttyfd> -b <baud> -y <tmp .kermrc>
  113.     #
  114.         $s_cmd = 'ckermit -l '+%itos(%conn)+' -b '+%itos(%baud)
  115.         $s_cmd = $s_cmd+' -y '+$s_rc+' -f'
  116.         echo 'executing "'+$s_cmd+'"'
  117.         system -s $s_cmd
  118.         fdel $s_rc             # remove tmp file
  119.  
  120. -----------------------------------------------------------------------
  121.  
  122. > I'm running on an Esix SVR4 machine and I am using ttymon.
  123. > Whenever I attempt to open my "default" serial port
  124. > "/dev/term/i1A" it will fail, telling me to readjust the
  125. > permissions (a chmod 666 /dev/term/i1A will solve this).  However
  126. > I was wondering if you have any plans on fixing this item?
  127.  
  128. ECU is incompletely ported from SCO in that the ecuungetty
  129. feature only works on SCO.  Ecuungetty, a setuid program, looks
  130. through utmp and at lock files to determine the availability of a
  131. line.  If a line is free, ecuungetty chown/chmod's the line so
  132. ECU can get at it.  When the line is close, ecuungetty is again
  133. called to re chown/chmod the line to uucp.  This makes ecuungetty
  134. exceptionally system dependent.  There is a small amount of
  135. similar code in ECU too.  Any volunteers?
  136.  
  137.  
  138. > I've heard about your ECU program for SCO Unix. I would like to
  139. > compile it under BSD (namely Ultrix). Is there a version for Ultrix
  140. > available somewhere in the Internet ?
  141.  
  142. Alas, ECU requires System V termio.  Adding BSD line I/O is
  143. unanticipated at this time.  I need to revive tipx, which
  144. provides X/Y/ZMODEM support to 4.3 BSD tip.
  145. -----------------------------------------------------------------------
  146. > When I get half finished with a download of a meg in size and it dumps,
  147. > I get wishing that I could tell the zmodem part of ecu that I
  148. > want it to tell the other end to start sending at a later point.
  149. > More specifically, I want it to find the file the other end is
  150. > sending, discover the filesize%1024 and tell the distant end to 
  151. > begin sending at that point, not at 0.  Is this available already,
  152. > or should I look at (and hack) your zmodem code?
  153.  
  154. The sz function supports resume transfer, but I know of no way
  155. for you the rz user to force the resume from your end.
  156. There is a resume feature present... the sender must support it
  157. and you must instruct him to do it.
  158.  
  159. For instance:
  160.     sz -r big.file
  161.  
  162.     -r Resume/Recover interrupted file transfer (Z)
  163.  
  164. This merely makes the receiver send an initial ZRPOS of local
  165. file size minus 1024 instead of the usual ZRPOS 0.
  166.  
  167.  
  168.  
  169. ------------------------------------------------------------------------------
  170. Warren Tucker                             n4hgf!wht or wht@n4hgf.atl.ga.us
  171. All readers cannot be leaders, but all leaders must be readers. - Harry Truman
  172.